Day 09｜Authorization Code Grant：OAuth 2.0 最核心的授權流程

2026 iThome 鐵人賽

DAY 9

Software Development

從登入到授權-現代軟體的身分架構指南系列第 9 篇

18th鐵人賽 authorization code code flow oauth 2.0 authorization

Gloria Chen

2026-09-17 00:07:08

20 瀏覽

分享至

前言

上一篇建立了 OAuth 2.0 的四個角色與抽象協定流程，也提到 Authorization Grant 不等於 Access Token。嚴格來說，現在最推薦的做法是 Authorization Code + PKCE；不過在理解 PKCE 之前，必須先看懂最基礎的 Authorization Code Grant。所以這篇會先把原始流程拆一遍，包括每一步實際傳送的參數，以及為什麼它要設計成「先拿 Code、再換 Token」。

今天內容涵蓋:

Authorization Code Grant 是什麼
完整流程走一遍：以串接 Google Drive 為例
每個步驟實際傳送的參數
安全性設計

一、Authorization Code Grant 是什麼

RFC 6749 4.1 節定義的 Authorization Code Grant，核心思路是：不要讓 Access Token 直接出現在瀏覽器 URL 上，而是先拿到一段「一次性、短時效」的 Authorization Code，再由 Client 用這段 Code 向 Authorization Server 換取 Access Token。

如果要跟 Day07 的 OAuth 1.0 三腳流程對照，可以這樣理解：兩者想解決的問題很像，都是「第三方 App 不要直接拿使用者密碼，而是讓使用者授權後，再取得可以存取資源的憑證」。

差別在於，OAuth 1.0 用的是 Request Token、oauth_verifier、Access Token 這套流程；OAuth 2.0 則把角色拆得更清楚，改成由 Authorization Server 發出 Authorization Code，再讓 Client 用 Code 換 Access Token。也就是說，Authorization Code Grant 不是 OAuth 1.0 三腳流程的原封不動延續，而是 OAuth 2.0 重新設計後，用來處理「使用者授權第三方 App」這個場景的主要流程。

二、完整流程走一遍：以串接 Google Drive 為例

接下來以「第三方 App 串接 Google Drive」作為例子，實際說明完整授權流程：

使用者在 App 裡點擊「連接 Google Drive」。
App 把使用者導向 Google 的 OAuth 授權端點（/authorize），並帶上 client_id、redirect_uri、scope、state 等參數。
Google 顯示同意畫面（consent screen），列出這個 App 要存取哪些權限。
使用者按下「允許」。
Google 導回 App 指定的 redirect_uri，並在網址上帶一段短時效的 Authorization Code。
App 的後端拿著這個 Code，加上 client_id、client_secret，向 Google 的 Token 端點發送後台請求，交換 Access Token（這一步瀏覽器看不到）。
Google 驗證 Code、Client 身分都正確後，回傳 Access Token（可能還有 Refresh Token）。
App 帶著 Access Token 呼叫 Google Drive API。
Google Drive API 驗證 Token 有效，回傳使用者的檔案清單。

三、每個步驟實際傳送的參數

前台請求（導向 /authorize）常見帶的參數:

參數	說明
response_type	固定填 code，表示要走 Authorization Code Grant
client_id	App 註冊時取得的公開識別碼
redirect_uri	使用者同意後，Authorization Server 要導回的網址，必須跟註冊時登記的完全一致
scope	這次要請求的權限範圍，例如 drive.readonly
state	用來防止 CSRF 的隨機字串，App 自己產生，等 redirect 回來時要比對

後台請求（換 Token）常見帶的參數：

參數	說明
grant_type	固定填 authorization_code
code	上一步拿到的 Authorization Code
redirect_uri	跟前一次請求相同的值
client_id / client_secret	App 的身分憑證，證明這個換 Token 的請求真的來自合法後端

這一步是在瀏覽器看不到的後端請求中完成。對傳統的 Authorization Code Grant 來說，這裡會出現 client_secret，用來證明拿 Code 換 Token 的請求，真的來自合法的 Client 後端。

四、安全性設計

將 Authorization Code 與 Access Token 拆成兩個階段，不是多餘的設計，而是發展出一套完整的防護機制：

state 參數：防止 CSRF 攻擊——App 自己產生一個隨機值，回來比對是否一致，避免使用者在不知情的情況下，被誘導接受攻擊者偽造的授權結果。
Authorization Code 短效且只能用一次：通常 60 秒到 10 分鐘內就會過期，就算被攔截，能被濫用的時間窗也很小。
client_secret 只用在後台換 Token 這一步：確保換 Token 的請求真的來自合法 App 後端，而不是任何攔截到 Authorization Code 的人。
redirect_uri 必須與註冊完全一致：避免使用者被導到攻擊者控制的網址。

⚠️如果 Client 是 SPA、行動 App 等「無法安全保存 client_secret」的公開客戶端，Authorization Code Grant 必須搭配 PKCE（Proof Key for Code Exchange）才安全——這是目前所有公開客戶端的標準做法。

小結

Authorization Code Grant 是 OAuth 2.0 裡最核心、也最常見的授權流程。它的重點是先讓 Authorization Server 回傳短效、一次性的 Authorization Code，再由 Client 後端拿這段 Code 去 Token Endpoint 換取 Access Token。

這樣可以避免 Access Token 直接暴露在瀏覽器網址中，也能讓 Client 在後端換 Token 時驗證自己的身分，降低 Token 被竊取或誤發給攻擊者的風險。

整理 Authorization Code Grant 的重點：

先拿 Code，再換 Token：Authorization Code 是中繼憑證，不是最後拿來呼叫 API 的 Token。
Token 交換發生在後端：Client 會在瀏覽器看不到的後端請求中，用 Authorization Code 向 Token Endpoint 換取 Access Token；傳統 Web App 也會在這一步帶上 client_secret 證明自己的身分。
安全性依賴多個檢查點：例如 state 防 CSRF、redirect_uri 必須完全一致、Authorization Code 短效且只能使用一次。

不過，對 SPA、行動 App 這類無法安全保存 client_secret 的 Public Client 來說，單靠傳統 Authorization Code Grant 還不夠。下一篇會接著看 PKCE 如何補上這個缺口，讓「先拿 Code、再換 Token」這個流程更適合現代前端與行動應用。